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"Method and System for simulating communications 
networks, object and computer program product therefor" 

5 Field of the invention 

The- present, 'invention refers to techniques for 
simulating communications networks such as, for 
instance, radio-mobile ceilular networks, . 

. The simulation, is an essential step in planning, 

10 designing, realizing and/ managing such networks, 
especially in view of the optimisation of performances 
of the networks themselves. Particularly/ the 
simulation plays an important role both at check level 
for planning a . new network, and at updating and 

15 optimising. : level . for performances of an already 
operating network. 

The invention has been devised paying particular 
care to the techniques of survey of inherent statistic 
data to the behaviour of the simulated network. Typical 

20 examples of statistic data that can. be measured in a 
radio-mobile cellular network system simulator are 
network capacity, mean delay on packet transfer, 
percentage of blocked calls, etc. 

Description of the prior art '* 

25 It is known- that there .are cellular radio-mobile 

network system simulators characterised by an. object 
architecture, such as disclosed, for ^example, in WO-A- 
02/104055. According to the object-' approach, the 
elementary decomposition unit is not the operation 

30 (method), but the object, meant as model of a real 
entity (a real -world object) . 

It is known that" in such simulators there are 
modules or devices adapted to simulate thei behaviour of 
physical network devices. Every module or device can 

35 have many implementations . (according to simulated 
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functionalities or. technologies) and each of these 
implementations can be used at will in the simulations: 
a different .way of .operating of the module in itself 
corresponds .to each implementation. It is also known 
5 that the .modules' or devices in, the simulator' mutually 
exchange information,, with the purpose of simulating 
the behaviour of real physical network devices; the 
exchange of information occurs through two modes: with 
"messages" and with ?"fervents". 

10 The communication with messages is characterized 

in that the receipt of information by the target module 
occurs simultaneously with, the dispatch from the source 
module; instead, the- communication with events is 
characterized in tiyat the receipt of information from 

15 the target module does not occur simultaneously with 
the transmission from the source module, but in a 
particular . following / .tim6 , ' instant • after the 
transmission time: the. use. of* the events serves for 
timing the receipt of a piece of information from the 

20 receiving module. - 

It is also known that these simulators are able to 
perform measurements of . the behaviour of the various 
simulated modules or devices ,. providing some statistics 
related to these measurements as simulation results. 

25 In the arrangement described in WO-A-02/104055 the 

objects-simuiator. "architecture provides an engine in 
which there is an entity called 'Statistic Manager. Task 
of such entity "is performing, " by intercepting 
communications ' between . module and module, the 

30 measurements related ' -to the behaviour of modules or 
devices *themsielves and . processing statistics of 
measured statistic data. 

A typical * example of statistic processing is the 
• computation of mean" transmission delays of a .packet . In 

35 this case, the Statistic Manager entity performs, for 
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every packet transmitted .in the simulated system, a 
delay measurement, averaging among them the various 
measured del-ays, obtaining the mean delay as result . 

It is Tcnown that - with analogous operating 
5 criteria - all interesting statistic * processing in a 
system simulator can b£ realised, for instance for 
radio-mobile cellular networks. 

The Applicant has observed that in a situation of 
the previously described, type, various types of 
10 problems occur that are . intrinsically tied up to the 
possible and frequent presence of different 
implementations of the same .network functionality, 

Firstly, the communication among two modules 
occurs directly through the Respective inplementations: 
15 in every -implementation of a given module, it is 
therefore necessary;^ to insert, for . the Statistic 
Manager's benefit, all information that identify 
communication modes ' with all implementations of the 
other modules with which the affected module can 
20 communicate. 

Secondly^ the. 'mechanism with which the Statistic 
Manager measures the -' behaviour of the modules or 
, devices changes according to implementation, because it 
has to" suit itself for ,thq- particular module/device 
25 implementation. , . ' ' 

Insofar, depending on : known prior art, with the 
purpose to be able to take into account the presence of 
many implementations of the same device or module, it 
is necessary to insert in 1 the Statistic Manager a 
30 specific interception and - measuring mechanism, 
operation that can be also very costly in terms of time 
and processing complexity. 

It will also be appreciated that this is worth 
above - all for the telecommunications networks (where 
35 the same network f uncticmality is performed by 
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apparatuses supplied by different manufacturers, with 
different implementations) and that the same type of 
problems occurs, in substantially identical terms, also 
in the communication- between various modules or 
5 devices, therefore, in . a way. that is independent from 
the intervention of the " Statistic Manager or an. 
equivalent entity , • . 

. Object and synthesis of ' the present invention 
Object , of the present, invention - is therefore 
10 solving the . above-mentioned problems . - 

According to the" present invention, such object is 
reached thanks to a method* having the characteristics 
specifically .stated 'in the claims that follow. The 
invention also relates to the corresponding system 
15. (simulator), to the objects included in the s^me, as 
well as to a corresponding computer program product 
loadable in the memory of at-, least one electronic 
computer and comprising portions of software code to 
perform th£ method according to the' invention when the 
20 product is executed on a computer: in this context such 
term must be deemed entirely equivalent to means 
readable by a .computer comprising instructions to check 
■ a network of computers in order to perform the method 
according to the invention. The .reference to "at least 
25 one electronic computer" is obviously aimed to show the 
possibility of performing the solution according to the 
invention in- a de- centralized context. 

In its currently -preferred embodiment, the 
invention solves the above r mentioned problems by 
30. introducing for the modules or devices in the simulator 
• respective interfacing, objects s with the other modules. 
. Such' interfacing objects have an .'"external" side and an 
"internal" side with respect to "module or device. Such 
external side, has an independent character from the 
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idiosyncrasies of said module or device and is 
therefore uniform for all system modules or devices. 

The term "uniform 11 obviously means such a 
character that the "external" side of said interfacing 
5 objects is independent frbm the respective module or 
device, and can thereby be substantially identical for 
all modules or devices. 

The previously- mentioned problems, intrinsically 
linked to the . possible presence of different 

10 implementations of network functionality, are thereby 
solved, also as regards to the* possible intervention of 
the Statistic Manager or an equivalent entity. 

In a particularly preferred way, the following 
interfacing' objects are introduced-: 

15 - communication- interfaces* among all simulated 

modules and/or devices: interfaces of this type manage 
the communication -with "events" and with "messages" and 
make implementations of single modules independent from 
the type of communication that every module is able to 

20 perform with. other modules in the simulator. 
Particularly, for every module/device there is a unique 
communication interface for all different 

implementations, of the considered module; " every 
communication operation amoncj modules and/or devices 

25 occurs through the communication interfaces; 

- statistic interfaces of simulated modules and/or 
devices: the interfaces of this type make statistic 
surveys • performed -by the Statistic Manager entity 
independent from the implementation of simulated 

30 modules from which statistic data are detected. 
Particularly, there is an interfacing object for every 
single irrjplementation of the modules of interest; in 
this interfacing object, the measuring mechanism of 
. . statistic data from the corresponding module is 

35 realised in a simple way. The Statistic Manager entity 
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collects the detected data through the external side, 
made uniform, of interfacing objects and more directly 
from single modules. 

Brief description of the attached drawings 
5 The invention will be described, purely as a non- 

limiting example, * with reference to the attached 
drawings, in which: 

- figure is is a functional approximate diagram of 
a simulator of the herein described type, 

10 - figure ' 2 showSr the architecture of related 

communication interfaces, 

- figures 3, 4 and 5 show a possible organization 
of messages and events withiii a .simulator of the herein 
described type, 

15 - figure 6 .is a 'functional approximate diagram of 

a statistics managing' module in a simulator of the 
herein described type, 

- figures 7 and 8 show in* detail the architecture 
of the relative statistic interfaces, 

20 - figures 9 and lp are exemplified flow diagrams 

of the operating modes of the herein described 
simulator, and 

- figure XI synthetically shows the statistics 
operation within a simulator of the herein described 

25 type. ■ ,~ - 

Detailed description .of an embodiment, of the invention 
Figure* 1 shows the architecture of a simulator 10 

comprising an engine 11 in which there are all typical 

managing functionalities of the simulation of a 
30 telecommunications network, . such as a radio-mobile 

network, namely: 

- Parameter Manager .11a, 

- Event Scheduler lib, 

- .Factory Manager 11c, and 
35 - Statistic Manager, lid. 
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A device package 12 is then present in which the 
different devices 13 are contained, representative of 
the physical, network devices and the objects related to 
the scenario to simulate. 

Every device contains different modules 
related to the different functionalities managed by the 
device itself. 

Such a simulator, working in general among a 
set of input signals I^and a set of output signals O, 
can be implemented, for instance, on a computer with 
Intel Pentium III processor and Microsoft Windows 
operating system, ..using Microsoft Visual Studio 6.0 
development environment and ANSI C++- programming 
language. 

15 As shown in figure; 2, every module 13', 13 ■ » 

present in the device package 12 can have many 
implementations' 13b 1 ,, 13c 1 or 13b 1 ' , 13c r 1 , 13d 1 ' , each 
one related' for instance to a set of simulated 
functionalities or to a specific technology. 
20 The herein described arrangement* has the chance of 

having, for all implementations- of a module, a single 
communication, interface 13a N ' , 13a'',.. that is used in 
the information exchange with other modules . 

The concept is general and can be applied to any 
25 module or device in a cellular network simulator. 

Every u module has its own communication interface: 
interface 13a » for module 13' and interface 13a ''.for 
module 13 ' ' . 

Module 13' has two different implementations 13b' 
and 13c', and both use interface 13a' to communicate 
with other modules, as for instance with module 13 ' ' . 

Module. 13" has three different implementations 
13b' ', 13c". and 13d", and all' use Interface 13a" to 
communicate with the other modules, as for instance 
35 with module 13'. 
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The use of interfaces in the communication among 
* modules allows making * .the insertion of. new 
implementations of a module- simpler and quicker without 
having to manage from time to time the functionalities 
5 related to information exchange. 

Every* communication interface (or "interfacing 
object") introduces in fact an "external" side A and an 
"internal" side .»B with respect to module or device 
13b', 13c'\ or 13b' ■, 13c 1 1 and 13d' ■ . 
10 The internal side B reflects the characteristics 

(or "idiosyncrasies") of the specific module or device 
and, more particularly, of the specific implementation 
considered every time. 

Contrarily,' % the* external side ■ A of every 
15 interfacing object 13a 1 , 13a 1 » is uniform for all 
system modules or devices; and therefore for all 
possible ; implementations of the same. 

The term "uniform" obviously means such character 
for which the external side A . of the interfacing 
20 object^ is independent from the respective module or 
device,, arid can thereby be substantially identical for 
all modules or devices. ; 

Particularly, the - external side A of the 
interfacing objects is configured in order to allow the 
25 information interchange between modules or devices with 
two modes : . * 

- i) through "messages": the information exchange 
occurs through the use of objects called "messages" . 

Depending on the structure 'shown in figure 3, 
30 every "Message" 100 is characterised by an indicator of 
the source or sender module or device S, by an 
indicator of the target module or device "Target" 110 
and by the information exchanged among modules "Data" 
120. The communication with messages is characterized 
35 in that the receipt of information from the target 
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module occurs simultaneously with the transmission from 
the source module. 

- ii) through "events": the information exchange 
occurs through the . use of objects called ".events" . 
5 Depending on the structure shown in figure 4, every 
"Event" 200. is characterised by an indicator of the 
source or sender module -or device. S, by a "Time" 210, 
by ari indicator of the target module or device "Target" 
220 and by information exchanged among modules "Data" 
10 230. The communication With .events is ' characterized in 
that the receipt of information from the target module 
does not occur simultaneously with the transmission 
from the source module, but in a particular time 
instant following the transmission time. 
15 The use of events serves for "delaying" the 

receipt of ,an- information from the receiving module. 
The communication with events occurs through the entity 
called- Event Scheduler that can be found in the 
simulator engine; function of the Event Scheduler is 
20 storing events . and relative time in a queue, called 
"queue of events", and sending every event to its own 
target module when the simulation time reaches the 
event time itself. » 

The ' implementation of every communication 
25 interface provides for four main functionalities, you 
respectively called: 

MessageDispatcher <MessageType> : dispatching 
functionality .of .messages -of the MessageType type, 
where MessageType represents any type of message; 
30 ~ EVentDispatcher <EventType>: dispatching 

functionality of events of the EventType type, where 
EventType represents any type "of event; 

MessageListener <MessageType> : receiving 
functionality of messages "of -the MessageType type, 
35 where MessageType represents any type of message; and 
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EventListener ,< Event Type > : receiving 
functionality <of events of the EventType type, where 
EventType represents any type of event . 

Every dispatching or receiving functionality of 
5 messages/events 6an be found or not in the 
communicatidii interfaces. 

It is possible to. have interfaces with only a 
subset of possible functionalities , for instance an 
interface can be . only MessageListener of a message 
10 . without* necessarily having the other three 
functionalities. 

Besides, in a single ' interface, the same 
functionality can be present many times, in order to 
manage different messages/events. For • example, an 
15 interface that has to be able to receive two typels of, 
different events has two EventListener functionalities: 
one for the first type, of event and another for the 
second type of event . 

As further example (not to be meant as; limiting of 
20 the scope of the invention) what is shown in figure 5 
can be taken into account,. % 

Here there are typ£s . of events ".Event A" 1000, 
"Event j 1010 and "Event C" 1020, the types of 

messages "Message 1" 2000 and ."Message 2" 2 010 and the 
25 interface related to module "Module ABC" 3 000 thatt it 
is able of: 

- receiving and sending events of the "Event A" 

type 

- receiving events of the "Event B" type 
30 r sending events of the "invent C" type 

- receiving message "Message 1", and 
-sending message "Message 2" 

The ' related interface has the following 
functionalities active: • [ 
35 - EventListener. <Eyent- A> 30ia 
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- EventDispatcher <Event A> 302 0 

- Event Listener <Event B> 303 0 

- EventDispatcher ' < Event C> 3040 

. - Message Listener <Message 1> 3050 , and 
5 - MessageDispatcher <Message 2> 3060 ' 

The realization of the simulator interfaces can 
advantageously be performed with C++ programming 
language. 

In case of the above -described example we have the 
10 following code: 

class Event 

i 

. ( 

GenericEventDispatcher * source 
15 GenericEventListener * target 

Int timej 

} 

class EventA . 
: public Event 
20 { 

} ' 

class EventB 
: public Event 
25 { 

} 

class EventC 
: public Event 
30 { 

} 

class Message 

{ 

35 GenericMessageDispatcher * source 
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GenericMessageListener * target 

} 

class Messagel 
5 : public Message 

{ . 
} 

class Message2 
10 : public Message 

{ 

> . • ■ 

class ModuloABC_Interf ace 
15 : public EventListener <BventA> 

, . public EventDispatcher <EventA> 

, public EventListener <EvfentB> 

, public Event Dispatcher *<EventC> 

, public MessageListeher <Messagel> 
20 , public MessageDispatcher <Message2> 

{ 
} 

class' ModuloABC 
25 : public ModuloABC_Interf ace 

[..-] 
{ 

[-..] XBC module implementation 

> : • 

30 The use of simulator interfaces also involves the 

architecture related to Statistic Manager. 

In the simulator, statistic processing is the task 
of the Statistic Manager -lid entity that can be found 
in the engine (see figures 1 and 6) . 
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The '.Statistic Manager lid contains the objects 
that store the various statistics, called "Statistic 
Calculators". . 

Figure 6 shows as an example three entities SCI, 
SC2 and SC3, every . one operating- as statistic 
calculator related to the processingj of- a particular 
statistic quantity: .SCI can. for instance be related- to 
system capacity, SC2 . related to mean transmission 
throughput of the packets, SC3 related to the level of 
power used in * transmission by the simulated radio- 
mobile terminal . 

The operation .of the affected computers is 
independent from the implementations of the simulated 
- modules and is only function of the types of statistic 
15 samples tp analyse. 

The herein described - arrangement provides that, 
for every implementation of a module, an adequate 
statistic .interface is realized, referenced by the name 
"Data Collector" , whose aim is collecting the statistic 
20 samples of interest • from the corresponding 
implementation and sending them to the Statistic 
Manager entity, that proceeds then to their processing. 

As a non-limiting example, figure 7 can be taken 
into account, where there is a device 12 0 in which two 
25 modules 121. "and 123 are present. 

Module 121 has two different implementations 121a 
and* 122a. 

For every implementation, there is a statistic 
interface (Data Collector) : implementation 121a 
corresponds to statistic interface 121b, implementation 
122a corresponds to statistic interface 122b. 

Module 123. iias three, different*" implementations 
123a, 124a and 125a. 

For every implementation there is a statistic 
35 interface (Data Collector) : implementation 123a 
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corresponds to statistic interface 123b, implementation 
124a corresponds, to statistic interface 124b, 
implementation 125a corresponds to statistic, interface 
125b. 

5 Also in this case, every communication interface 

'or interfacing object has in fact an external side A 
and an internal side B with respect to module or device 
121a, 122a or 123a, 124a and 125a. 

The internal side B reflects the characteristics 
10 or idiosyncrasies of the specific module or device and, 
more particularly, of the specific implementation 
considered every time. 

Contrarily, the . external side A of every 
interfacing object 121b, 122b or 123b, 124b, 125b is 
15 uniform for all system modules, or devices and therefore 
for all possible implementations of the same. * 

The external side A of the interfacing objects is 
therefore independent from the respective module or 
device, and can thereby be substantially identical for 
•20 all modules or devices. 

As an explanation and example, it can be supposed 
that module 121 manages the transmission of a packet; 
in this case a statistic sample of interest is the time 
employed to transmit every single packet. Therefore, 
25 every ; statistic interface 121b .and 122b of the 
different implementations of module 121a and 121b must 
be able to identify aridi collect the time used to 
transmit a packet from the corresponding implementation 
of module 121. 

30 In general, the two mentioned implementations of 

module 12la arid 122a totally' manage the transmission of 
* a packet . in different way" therefore the two 
corresponding statistic interfaces 121b and 122b have 
to measure the time of transmission of a packet with a 

35 different mechanism. 
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The implementation of * every statistic interface 
..preferably provides for a functionality DataDispatcher 
<DataType>, namely a dispatching functionality of 
statistic data of the DataType type, where DataType 
5 represents any statistic data type. 

As further non- limiting example, what is shown in 
figure 8 can be taken into account , where in the left 
part there are the types of statistic data "Data A n 
1100, "Data B" 1101 and "Data C" 1102, and in the right 
10 part there are the statistic interfaces related to 
module "Module 1" 1300 and to module "Module 2" 1301. 

The interface related to module "Module 1" 1300 
are able to send* statistic data of the "Data A" 1100 
type and of the "Data C" 1102 type. 
15 The interface related, to module "Module 2" 1301 

are able to send statistic data of the "Data B" 1100 
type and of the "Data C» 1102 type. 

Then the interface related to module "Module 1" 
1300 has the following functionalities active: 

- DataDispatcher <Data A> 1300a 

- DataDispatcher <Data C> 13 00b. 

The interface related to module "Module 2" 301 has 
the following functionalities active: 

- DataDispatcher <Data.JB> 13 01a 
25 - DataDispatcher <Data C> 13 01b * 

The realization of statistic interfaces in the 
simulator is preferably performed with programming 
language C++. 

In case of the ■ above -described example, we have 
30 the following code: 
class DataA 

{ 

[. . .] 

} - : 

35 
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class DataB 

{ 

u..) • 
} 

5 

class DataC 
{ 

I...) 
) 

10 

class Modulol_StatisticInterf ace 
: public DataDi spat cher <DataA> 
, public DataDi spat cher <DataC> 

class Modulo2_StatisticInterf ace 
: public DataDi spat qher <DataB> 
, public DataDispatcher. <DataC> 
20 { 

} 

The operation of dispatching a message is shown in 
figure 9 and is described as follows: 

- step 1001: the iirgplementation of sender module 
25 sends the message to its own interface MessageType; 

- step 1002: the interface, of sender module sends 
the message MessageType to the interface of the 
receiving module; 

- step 1003: the interface of the receiving module 
30 receives • the message MessageType and sends it to the 

implementation of the module. 

The operation of dispatching an event is" shown 
instead in figure 10 and is described as follows: 
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step 2001: the implementation of the sender 
module sends the event to its own interface EventType, 
pointing out the time of receipt t; 

- step 2002: the interface of the sender module 
5 sends Event Scheduler to the entity, the event 

EventType pointing out the time* of receipt t; 

- step 2003: when the simulation reaches the time 
t, the entity Event Scheduler sends the event EventType 
to the interface of the target module; 

10 - step 2004: the interface of the receiving module 

receives the event EventType and sends it to the 

implementation. of the module* 

» 

The general operation of the method for collecting 
statistic samples, in a given simulator is shown in 
15 figure 11, where as kn example the Statistic Manager 31 
manages three statistics (Statistic Calculator) 31a, 
31b and 31c. Statistic 31a processes samples type K, 
that obtains from .a first module having two 
implementations 32a and 33a, which respectively 
20 correspond to statistic interfaces 32b and 33b. 

The collection of statistic samples occurs as 
described as follows: 

- during simulation/ statistic interfaces 32b and 
3 3b identify samples type K, each one with a proper 

25 mechanism that takes into .account the functionalities 
of the corresponding implementations 32a and 33a; 

- at every simulation step, the Statistic Manager 
queries the statistic interfaces so that they send 
directly Collected samples type K to statistic 31a; and 

30 - with a suitable interval, statistic 31a 

processes samples type K and sends forth' the result. 

The herein described arrangement essentially 
involves two^rapn advantages. 

Firstly, the communication mode between simulated 
35 modules and devices is independent from individual 
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implementations of modules/devices. In this way, the 
information exchange modes* between modules and devices 
are established once and. for all defining the 
communication interfaces of every module and device . 
5 Every time it is decided to introduce in the simulator 
a new implementation for a device or for a module, it 
is not necessary to worry about the 'management of 
information exchange because this is already managed. 

Secondly, it is possible to rationalize the 

10 planning of statistics managed by the Statistic Manager 
entity since it does • not depend from which 
implementations of devices or modules are used in the 
simulation. In ;this way, every time it is decided to 
introduce in the- simulator a new implementation for a 

15 device or for a module, it is enough to realize the 
corresponding- statistic . interface (Data Collector) , 
without having to modify the operation of the Statistic 
Calculator, . 

As a result "of the described situation, a flexible 
20 and slender general architecture of the simulator is 
obtained. 

As already said, the implementation of the 
described simulator can fcje realized with any type of 
computer; such as Intel, SUN, Apple, . . . and with any 

25 operating : system (Windows, Linux, Unix, MAC OS...) - The 
use of ANSI C++ programming language is. only a possible 
choice; the implementation of the- simulator can be in 
fact also performed in other programming languages, 
such as Java, Delphi, Visual Basic,... 

30 The choice of ANSI C++ language appears currently 

preferred in view of the good planning flexibility 
offered by said programming language and of the high 
level of obtainable performances in the finished 
program in terms of execution speed. 
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The invention can be used in cellular networks 
simulators that simulate other systems besides the 
mentioned GSM, GPRS .and UMTS. The invention can be used 
in cellular networks simulators that adopt the events 
5 simulation technique -or the Montecarlo simulation 
technique . 

The skilled technicians in the art will 
immediately appreciate that the invention does not 
necessarily deal with the only simulation of radio- 

10 mobile cellular networks: the invention can in fact be 
also used in other types of simulators, where there is 
a similar . architecture with' modules and* devices 
complying with real physical equipment and where it is 
necessary to communicate among various modules/devices 

15 the parameters related to simulated functionalities. 

It is therefore evident tjiat, notwithstanding the 
principle! of the invention, the realisation particulars 
and the embodiments can be broadly changed with respect 
to what has been described and shown, without departing 

20 from the scope of the present invention, as defined by 
the attached claims. 



